This would be great for my own use case (to the point that I've included this patch in my own bindings). I have a couple of questions:

If I'm not mistaken, the API consumer is now responsible for free()ing and resetting msg after an error, is this correct?

Might it be a good idea to have an errno struct member set to the appropriate RTMIDI_ERROR constant as well? I think retaining the msg pointer is good for those needing ABI stability (i.e. me), but knowing the nature of the error without having to inspect the string could be useful.

Cheers!

Hey, sorry for the late reply. Didn't work much on it recenlty so I don't really have the context anymore, I'd need to check. But tbh this repository seems kinda dead and outdated, if I had to rewrite web bindings for midi, I'd probably use this library instead : https://github.com/celtera/libremidi

It uses modern C++ and offers C bindings, it includes midi 2.0 spec, and is actively maintained.

Good luck :)

I wouldn't call this project dead -- MIDI 1 is not exactly a moving target so I don't think a release is required that frequently :)

Cheers for the heads up on libremidi - I had ignored that in the past due to the lack of a C interface. Thanks!

Yeah of course it works fine and has not many reasons to evolve, but what I meant is that this PR, for example, got absolutely no answer or comment, not even to say it's bad or anything, so I don't know what should be expected of it...

I'm trying to see if I can generate an FFI binding to libremidi for my Deno midi library, there's a bit of effort but it should be doable.

Given the potential memory leak issue noted, as well as the fact that I don't use the C functionality myself, I will wait to see if others have opinions on this PR.